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1, BACKGROUND 

The Mult iMiss ion Control Team (MMCT) 
consists of mission controllers which 
provides Real-Time operations support 
for the Mars Observer project. The 
Real-Time Operations task is to 
insure the integrity of the ground 
data system, to insure that the 
configuration is correct to support 
the mission, and to monitor the 
spacecraft for the Spacecraft Team. 
Operations systems are typically 
developed by adapting operations 
systems from previous projects. 
Problems tend to be solved 
empirically when they are either 
anticipated or observed in testing. 
This development method has worked in 
the past when time was available for 
extensive Ops testing. In the present 
NASA budget environment a more cost 
conscious design approach has become 
necessary. Cost is a concern because 
operations is an ongoing, continuous 
activity. Reducing costs entails 
reducing staff. Reducing staffing 
levels potentially increases the risk 
of mission failure. Therefore, 
keeping track of the risk level is 
necessary. 

2. INTRODUCTION 

The role of the MMCT is to interact 
with the process (Mars Observer 
mission) to accomplish required 
tasks. The organizations design 
discussed here is to develop an 
organization of people, equipment, 
software, and procedures that will 
accomplish these tasks. The goal is 
to provide a design technique that 
can produce an operations 
organization that will meet the 
requirements placed on it, with 
minimum costs and with the 
understanding of the risks involved. 


The design approach is based on 
considering the Mars Observer mission 
as a process. The Mars Observer 
mission is a rather linear process. 
The spacecraft is launched; then, it 
goes through a well specified 
sequence of actions until the end of 
the mission. 

The following Operations System 
design approach was developed for the 
design of the MMCT to support the 
Mars Observer mission. 

The design technique consists of: 

Identifying the Mars Observer Mission 
process. 

Modeling the process. 

Identifying the requirements imposed 
by the Mars Observer Project on the 
MMCT. 

Synthesizing the MMCT scenarios that 
respond to the mission requirements, 
both imposed and implied 
requirements. 

Derive requirements for support from 
other parts of the operations 
organization. 

Analyzing scenarios for staffing 
requirements, training requirements, 
workload problems, etc. 

Reviewing the imposed requirements 
from the Project for feasibility. 
Requirements that cannot be 
accommodated are negotiated. 

Developing staffing plans, training 
plans, test plans, etc. 
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The Mission sequence model is 
documented in the MMCT Design 
Document* The Project requirements 
and the MMCT operating scenarios are 
integrated into the design document. 

This approach to the design of the 
MMCT provides a more complete 
understanding of the mission 
processes and a cost effective method 
of the tailoring of the MMCT 
operations system to support the Mars 
Observer mission. The purpose of 
this paper is to present this 
approach and discuss its merits. 

3. APPROACH 

The Mars Observer mission process is 
identified from the Mars Observer 
Mission Sequence Plan (Ref . 1). This 
document identifies the spacecraft 
activities that are to be supported 
by the MMCT. The Mars Observer 
Mission Operations specification 
Volume 3: Operations (Ref. 2) 
present the requirements that the 
MMCT must meet to support the 
project. 

The mission sequence is modeled in a 
form that allows for hierarchic 
refinements. To facilitate this 
effort, the commercial computer 
program SDDL was chosen. SDDL is a 
Pseudo English language intended 
for software program design. The 
Mars Observer Mission Sequence Plan 
was the basis for decomposing the 
mission process from an overall 
description through subprocesses to 
elementary processes . Typically, 
these elementary processes were 
sufficiently simple to be described 
on a single page. SDDL provided the 
capability to reference subprocesses 
through CALL statements in the manner 
of a software subroutine. Figures 1 
and 2 illustrate the decomposition 
of the mission process. 

Verification of the process model is 
provided by joint reviews between the 
Mars Observer MMCT design team and 
the Spacecraft Control Team (SCT) . 
The requirements presented by the 
Mars Observer Project are analyzed in 
terms of their impact on the Mars 
Observer MMCT organization system. 
The requirements are clarified so 
that they are consistent for both the 
originating and the responding 
organizations. The imposed 
requirements are integrated into the 


design document where they apply. 
SDDL has the capability of indexing 
the requirements and placing the 
index at the end of the design 
document. Figure 3 illustrates the 
requirements and the requirements 
index. 

MMCT operations scenarios are 
developed to accomplish the required 
tasks. They are written into the 
Mars Observer process model to form 
the MMCT Design Document. Scenarios 
that satisfy the imposed requirements 
are integrated with the requirements 
to provide requirements traceability. 
Operations scenarios are illustrated 
in Figures 2 and 3 . 

The requirements are then negotiated 
between the Mars Observer MMCT and 
the Mars Observer Project. 
Requirements are accepted, waived, or 
when problems exist workaround 
solutions are identified. The 

requirements are refined and 
documented in the design document. 

The operating scenarios are reviewed 
by experienced mission controllers. 
Experience from prior missions is 
used to test the validity of the 
scenarios. A person with actual 
experience usually can tell whether 
a task (scenario) can be accomplished 
in the time required and w’th the 
resources allowed. 

From the Mission Controller Team 
scenarios, the resources required to 
support the Mars Observer mission are 
identified. These resources include 
staffing, data, hardware, software, 
work- station displays, procedures, 
logs, reports, and management 
interactions. Displays that are 
required to support specific MMCT 
tasks are identified, specified, and 
indexed in the design 
document . 

Derived requirements identified above 
are placed in the Design Document at 
their point of application and again 
are indexed with the SDDL indexing 
capability. Derived requirements are 
illustrated in Figures 2 and 4. 
Derived requirements are requirements 
that are derived from the exposition 
of the operating scenarios. They are 
the data, procedures, equipments, 
support, etc. that are recognized as 
needed to accomplish the required 
MMCT tasks . 
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Discrepancies discovered in the 
process of developing and analyzing 
scenarios are recorded as unresolved 
issues. Unresolved issues are 
identified and indexed. This allows 
unresolved issues to be tracked. The 
unresolved issues index is 
illustrated in Figure 5. 

Scenarios are analyzed and workload 
studies are performed. These 
workload studies are used to identify 
when controllers are overloaded. 
They also identify when one 
controller may be available for 
additional mission responsibilities, 
thereby improving multimission 
operation. 

The detailed workload studies and 
requirements analyses indicate when a 
specific spacecraft sequence 
overloads the mission controller, or 
when resources are not adequate to 
support the mission operations. 
This provides an understanding of 
specific risks of failure. It 
provides the basis for the MMCT 
development team to negotiate 
additional staffing, specific 
workstation displays, software tools, 
data validation programs, additional 
spacecraft or mission information, or 
if required additional time to 
accomplish specific tasks. 

The MMCT Design Document then 
provides the basis for staffing and 
training plans. The design document 
provides the basis for determining 
whether the mission controller will 
be operating the Knowledge based 
mode or the Procedural based mode. 

One of the basic parameters of 
designing an operations system is 
whether the operation will be 
Knowledge based or Procedural based. 
That is, will the normal operation be 
based on the operators knowledge of 
the process or will the operator 
normally be guided by preplanned 
procedures. The advantage of 
Procedural based operations design is 
that the skill requirements on the 
operator is less than for a 
Knowledge based operations system. 
We can expect the operator costs to 
be less for Procedural based system 
than for Knowledge based system. 
Procedural based system design can be 
used when the basic process is well 
known and relatively simple (i.e. 
procedures can be written), and the 


basic system is stable (i.e. 
procedures are continuously valid) . 

When the basic system process is not 
well understood or the process 
changes, adequate procedures are 
difficult, therefore the system must 
be operated as a Knowledge based 
system. This requires that the 
operator be sufficiently 
knowledgeable of the system process 
that he can recognize when problems 
occur and can formulate plans to 
resolve the problems. The advantage 
of a Knowledge based system is that 
preplanning is minimized, and the 
operator responds to problems when 
they occur. If a Procedural based 
operation is appropriate, then the 
necessary procedures are identified 
and plans for developing them are 
generated. If a Knowledge based 
operations is more appropriate, then 
the necessary training plans are 
identified and developed. 

4. CONCLUSION 

The Mars Observer MMCT Design 

Document, as presented in the SDDL 
format, serves as the repository for 
the Mars Observer mission process 
model, the imposed requirements, the 
synthesized Mars Observer Controller 
responsibilities, the derived 
requirements, and unresolved issues. 

The Mars Observer MMCT Design 

Document provides the basis for 
developing operations procedures, 
staffing plans, and training plans. 

The Mars Observer MMCT Design 

Document provides a clear basis for 
the negotiation of resources with 
other organizations. It also 

provides the tracking of derived 
requirements and unresolved issues. 
It provides a tool for working out 
the details of the implementation. 
It provides the structure on which 
the details of the operations 
scenarios are analyzed to uncover 
problems and inconsistencies. 

The design techniques presented for 
the MMCT Operations design provide a 
clear, rational, cost effective 
design process. 

With a better understanding of the 
Operations System development come 
better cost control and risk 
management . 
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PROGRAM Mission Phase 

ft***********?**** ft********.***********.****.*******************'************ 

a This B&odul«s is the top level of the Mission activity hierarchy. * 

********************** ft ft*#* ft ******* ft* ft ft ******* ft*** ******** ******* ******* 
*4^4^4^4^4^++*++++*+++++**4-+*++++**4HH-++*+4^*+++**-*-+*4--M-'M-*++++*+++++-f--* 


* At any point in the MO Mission activity the KCT has 
the capability to: 


Transmit required commands to spacecraft 
Verify spacecraft receipt of commands 
Identify GDS conditions that interrupt or 
degrade command transmissions 
Assure continued acquisition, safeing of required data 
Verify accomplishment of the SOE 
Identify unexpected interruptions or degradations 
of the required data 

Initiate troubleshooting procedures when data product, 
command interruptions, degradations occur 
Coordinate CDS recovery from data product and 
command interruptions and degradation 
Develop, analyse real-time S/C, CDS trends 
Report observed spacecraft data anomalies to 6CT 
Respond to and coordinate real-time SOE changes 


+ Hote: A success-oriented mission activity is assumed In the 
+ following analysis 

SELECT Mission Phase 

CASE Launch 

CALL Launch_Phase- 

CASE Inner Cruise 

CALL Inner_Cruise- 

CASE Outer Cruise 

CALL Outer Cruise- 
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CASE Mapping 

CALL Mapping——— — — — — — — — — — > ( 


CASE Orbit Insertion 
' CALL Orbit Insertion- 


Si 

4) 

5) 

«■> 

?) 

PACE 


142 PROGRAM Inner Cruise 

143 ft*********************************************** 

144 * Mission actaivities in the Inner Cruise Phase 

ENl 145 ************************************************ 

146 

147 

148 

149 

150 

151 

152 

153 

154 

155 
lu 


SELECT Inner cruise phase sequence 

CASE Spacecraft checkout (Cl) 

CALL Spacecraft_Checkout— — — - 


CASE TCM 1 (C2) 
CALL TCM 1 


CASE Payload Checkout (C3) 
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PROGRAM ^ Spacecr a f t_Checkou t 


* ID Cl, Duration 13 days. Start 1+2 days. End 1+15 days * 

* Continuous DSN coverage • 

imimmmiHimmmmmimtm m minimum turn mmi 

I ASSUMPTIONS 1 

I The SCT is on duty l 

1 Ml Ml lit 111 It 111 1 11 1 11 111 Ml 1 1 1 lilt 1 1 1 1 1 1 i I 111 1 1! till 1 1111 11 1 till I II If. 


LOOP for duration of Cl 

CALL Monitor — ■ — — — — > ( 

Do the Cl activities as they are required 

CALL Cl_Activities— — • — > ( 


--- — ~ >( 

«) 

- / '< 

23) 



— >( 

25) 

— — >( 

32) 

- — — — >( 

34) 


->( 2 ) 


IF Shift change 

CALL Shift Change- 
ENDIF 


->< 


IF Station transfer 

CALL StationjTransfar— — ----- — — — — > ( 


ENDIF 

ENDLOOP 


Return to 

CALL Inner Cruise- 


55) 

9 ) 

48) 

51 ) 


> Figure 2 


Figure 1 
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PROGRAM ClActlviti®® 

SELECT 

CASE Launch playback, load a 

Stand command load CIA (1+1/ 12 s 00: 00) 


CALL Commanding™ — — — * — - — -* — >( 46) 

CALL ClA_Activities~ >( 11) 

CASE REDMAK load 

Sand command REDMAN load 

CALL Commanding--*-'-------’----——- — — — — —— — — — * — —— — > ( 46) 

CALL R£DHAN_Activiti®s-« “ ~ . -->( 13) 

CASE Propulsion priming, MAG k GRS boom extensions, load B 

Send command load C1B (1+3/12:00:00) 

CALL Commanding—™ — — — — — — - — —————— — — — ->( 46) 

CALL ciB_Activities———~— ————————— — > ( 14) 

CASE PDS health check k GRS calibration data, load C 

++•+++++++++++++++++++++++++++++++++++++++++»+++++++++++++ + +++++++++++ 
+ If any anomaly or other difficulty is encountered during + 

+ the spacecraft checkout, this sequence load may be emitted + 

+ to allow more time for the ground to interact with + 

+ the spacecraft. + 


Send command load CiC (1+5/12 : 00:00) 

CALL Commanding— — — — — — — — —————— — — — > ( 46) 

CALL ClC_Activities >( if) 

CASE Tank Pressurization, load D 

Send command load C1D to open valve 7 
(1+11/12:00:00) 

CALL Commanding— — ■ > ( 4 6) 

CALL C10_Activities — — — — — — ->( 18) 

CASE Tank Pressurization, Load E 

IF valve 7 was successfully opened 

Send command load Cl-E(P) to open valve 5 (1+13/04:00:00) 

CALL Commanding- — — — ——————— > ( 46) 

CALL C1EP Activities- — — — — — — — >( 20) 

ELSE 

Send command load Cl-E(B) to open 

both valves 5 and 8 (1+13/04:00:00) 

CALL Commanding ■ — — 4 6) 

CALL C1EB Activities-— — — >( 21) 

Q*DIF 

CASE Tank Pressurization, Load F 

IF valve 5 was not successfully opened 

Send command load C1F to open valve 6 (1+13/12:00:00) 

CALL Commanding- — — — — — — — — — — — — — — — — > ( 46) 

CALL C1F Activities———— — - >( 22) 

ENDIF 

ENDSELECT 
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288 PROGRAM CIA Activities 

289 «M*««***********«i*«**M*M*«*»**#«M*****«0*«M*««**H*H** 

290 * This is the scenario for the mission controller to handle * 

291 * the CIA activities * 

292 #*«***M****M**«*******«*MM*OMHO******#*****Mit**«*«**M*« 


norlufld I C1A activities scenario j 

uenv (IN. 01.1 CIA activities scenario should be reviewed With SCT) 


Requirement 

> 


Callup the -CIA display- 
'D.3. 1 CIA display' 


300 

301 

302 

303 

304 

305 

306 

307 

308 

309 

310 

311 

312 

313 

314 

315 

316 
31*7 

318 

319 

320 

321 

322 


Confirm USO selected (LQ013/L0020) (1+2/16:00:00) 

Confirm Ranging enabled (L0009/L0016) (1+2/16:00:00) 

Confirm RPA 2 filiment is off (L0029) (1+2/16:00:30) 

Callup -DTR display- 

Confirm that DTRl is active (C0016) (1+2/16:01:00) 

Confirm Sun Monitor disabled (?) ( 1+2/16 

[IK. 01.2 What is the Sun Monitor disabled channel number) <«-«-— 

Conf long-term gyro recovery enabled (F4064) (1+2/16:03:00) 


< MMCT Scenario 

Unresolved Issue 


Confirm new battery charge rate (1+2/16:04:00) 

Charge rate 1: E0501 2: £0503 

Voltage limits 1: £03 01(H) 

2: £0303 (H) 

Playback DTR3 at 8 kbps (1+2/16:30:00) 

CALL DTRP layback — — — — >( 41) 

Playback DTR2 at 32 kbpa (1+2/20:00:00) 


CALL DTRP layback — — >( 41) 

Return to 2 kbps ENG telemetry (1+2/23:00:30) 


Figure 2 
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1091 PROGRAM Station^Dafca_R©ca 1 1 
1892 

****^*®&&* & ®*® # <& & * & * 1&# * 1&,& *fc 16 * **«****•**••***■********* 

* The following procedure 1 b used to recall recorded data ® 

« fro® the station that for ®oto reason did not get into the PDB. * 


1093 

1894 

1895 

1896 

1897 

1898 

1899 

1900 


MMCT Scenario 


«»R 5.2.2. 1.7 Telemetry data gap®, playback" 


Requirement 


j Telemetry data playback from DSCC scenario | 

(XH.29.1 TLK data playback from OSCC scenarion need® validation) 
Request DSCC to playback required telemetry data 
Configure SFOC for DSCC data playback 
Confirm DSCC playback 

Confirm telemetry playback data received at PDB 
Log telemetry playback 
Return to 

CALL Outgo ing_Stat ion-- * * «• 


190/ 

1908 

1909 

1910 

1911 

1912 

1913 

1914 

1915 
1915 1NDPRQGRAH 


->( 52) 
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1979 PROGRAM imposed Requirements 

1980 

1981 ************♦*****♦***•************************************< 

1982 * All the imposed requirements are obtained from the 

1983 * Mission Operations Specification Volume 3: Operations 

1984 m ********** iM **** H * o *** u *******#**** m ************** 1 

1985 

1986 *R 2. 3. 1.3 Spacecraft and Ground Health Monitoring" 

1987 

1988 The FPSO/MCT shall monitor the spacecraft and GDS data when 

1989 provided with valid spacecraft/ground predicts, standards, 

1990 and limits. The following monitoring scenario supports 

1991 this requirement. 


Requirements Definition 


CALL Monitor 


"R 5. 2. 2. 1.7 Telemetry data gaps, playback" 


V In the event of telemetry data gaps that need to be filled to 

> meet Project requirements, the MCT shall coordinate with DSOT 

19*. and DAT to asure that telemetry data is recalled from the GIF 

1999 or DSCC as soon as possible after the end of the tracking pass 

2000 but not to exceed 12 hours. 

2001 CALL Station Data Recall--— —< — — .■ — — — — 

2002 “ “ 

2003 EKDPROGRAM 


>( 


>( 


>«r 
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53) 


Imposed Requirements 
CROSS REFEREHCE LISTIHG 

f lHI I lH I HU ii ♦+++ +44 4 - 14 f 4 4 +4 « 444-+++4+++++-+< 

R 2. 3. 1.3 Spacecraft and Ground Health Monitoring 
PAGE 56 PROGRAM Imposed Requirements 
R 5.2. 1.3 

PAGE 61 PROGRAM Unallocated Requirements 

R 5,2.1. 4 

PAGE 61 PROGRAM Unallocated^Requirements 

R 5. 2. 1.6.1 

PAGE 61 PROGRAM Unallocated Requirements 

R 5.2. 1.6.2 

PAGE 61 PROGRAM Unallocated_Requirements 

R 5. 2. 1.6.3 

PAGE 61 PROGRAM Unallocated_Reguire*ents 

R 5.2. 1.7.2 

PAGE 61 PROGRAM Unallocated_Require*ents 

R 5.2. 1.7.3 

PAGE 61 PROGRAM Unallocated Requirements 

R 5. 2.2. 1.1.1 ~ 

PAGE 62 PROGRAM Unallocated Requirements 

R 5. 2. 2.1. 1.2 

PAGE 62 PROGRAM Unallocated Requirements 

R 5.2, 2. 1.1. 3 

PAGE 62 PROGRAM Unallocated Requirements 

R 5.2. 2. 1.5. 2 

PAGE 62 PROGRAM Unallocated_Requirements 

R 5. 2. 2. 1.6 

PAGE 62 PROGRAM Unallocated Requirements 

R 5. 2. 2. 1.7 

PAGE 62 PROGRAM Unallocated Requirements 

R 5. 2. 2. 1.7 Telemetry data gaps, playback 
PAGE 53 PROGRAM Station_Data Recall 

PAGE 56 PROGRAM Imposed Requirements 
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1986 

2213 

2206 

2218 

2233 

2239 

2245 

2252 

2259 

2264 

2270 

2275 

2281 

2291 

1994 < Requirements index 


Figure 3 
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3007 PROGRAM Derived Requirements 

3008 

3009 '0*1 A top level display 1® required' 

3010 

3011 This display provides a G0/H0G0 indication of the configuration 

2012 and p®rfor®anc« of each of th© S/C and CDS system. 

2013 CALL Monitor—— — — — — — — — — 

2014 

2015 'D.2.1 0TR playback display' 

2016 

2017 A display is required to support the DTR activities scenarios. 

2018 CALL DTR Playback 

2019 CALL DTR~" Repack — — — — — 

2020 CALL DTR_End__o£_Record-— — — - — — — 

2021 


Derived Requirements 
Definition ? ns * 


'D.2.4 Spacecraft Maneuver display' 

A display is required to support the spacecraft maneuver 
scenario. 

CALL Kan«uv«r--‘------'-— 


V 

* V 'D.3.1 CIA display' 

20. A 

2030 A display is required to support the CIA mission segment. 

2031 CALL CIA Activities— 

2032 CALL REDMAN^ Activities— — — 

2033 

2034 'D.3.2 C1B display' 

2035 

2036 A display is required to support the C1B mission segment. 

2037 CALL C1B Activities — — — — 

2038 

2039 '0.3,3 C1C display' 

2040 

2041 A display is required to support the C1C mission segment. 

2042 CALL C1C Activities ■ — — 

2043 

2044 '0.3.4 CIO display' 

2045 

2046 A display is required to support the CIO mission segment. 

2047 CALL CIO Activities — — — 

2048 CALL C1EP Activities——* 

2049 CALL ClEB~Activities« 

2050 CALL C1F Activities— — — 

2051 

2052 '0.3.6 C3A display' 

2053 

2054 A display is required to support the C3A mission segment. 

2055 

2056 CALL C3A- — 

2057 
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41 ) 

42 ) 

43) 


24) 

11 ) 

13) 

14) 
17) 


18) 

20 ) 

21 ) 

22 ) 


26) 


Derived Requirements 

CROSS REFEREKCE LISTING PAGE 72 


0.1 A top level display is required 

PAGE 57 PROGRAM D«rived_Require»ents 
0.2.1 DTR display 

PAGE * * • 41 PROGRAM DTR Playback 

PAGE 42 PROGRAM DTR^Repack 

PAGE 43 PROGRAM 0TR_End_O f ^Record 

0.2.1 DTR playback display"* 

PAGE 57 PROGRAM Derived Requirements 

D.2.4 Spacecraft Maneuver display 

PAGE 57 ‘ PROGRAM Derived Requirements 
0.2.5 Spacecraft Maneuver display 
PAGE 24 PROGRAM Maneuver 

D.3.1 CIA display 

PAGE 11 PROGRAM CIA Activities 

PAGE 57 PROGRAM DerIved_Requirement8 

D.3.10 C5 display 

PAGE 34 PROGRAM Outer Cruise Transition 

PAGE 58 PROGRAM Derived_RequTraments 

D.3.2 C1B display 

PAGE 14 PROGRAM C1B Activities 

PAGE 57 PROGRAM DerTved_Requ ir ament s 

D. 3.3 CXC display 

PAGE 17 PROGRAM C 1 C Activities 

PAGE 57 PROGRAM Derived Requirements 

D.3.4 C1D display 

PAGE 18 PROGRAM C1D Activities 

PAGE 57 PROGRAM DerXved^Requirsments 


2009 

1522 

1570 

1629 

2015 

2022 

822 

< Derived Requirements Index 


1269 

2075 

403 

2034 

509 

2039 

543 

2044 


Figure 4 
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Unresolved Issues 
CROSS REFERENCE LISTING 


PAGE 73 


IK* 01- 1 CIA activities scenario should be rtfiwtd with SCT 
PAGE 11 PROGRAM Cl&_Act ivit less ***'* 

XM S 01*2 What in the Sun Monitor disabled channel number Unf0SOlV0d fe&SJ® Inrfav 

PAGE 11 PROGRAM CXA_Aet ivit ies ssiu^A 

IK. 01. 4 How to confirm that heads are parked 

PAGE 11 PROGRAM CXA_Activifci@s 345 

IN .02.1 REDMAN activities scenario should be reviewed with SCT 
PAGE 13 PROGRAM REDMAN_Activ£tlee 360 

IN. 02 . 2 What is the battery temp cont channel number 

PAGE 13 PROGRAM REDMANActivities 364 

IN. 02. 3 What is the battery charge contr channel number 

PAGE 13 PROGRAM REDHAN_Act ivit ies 367 

IN. 02. 4 I« E0001 the correct CN for battery backup charge? 

PAGE 13 PROGRAM REDMANAct Ivit ies 371 

IN. 02. 5 How is the contingency alert enable confirmed 

PAGE 13 PROGRAM REDMAN_Activities 374 

IN. 02. 6 How Is the telemetry verification enable confirmed 
PAGE 13 PROGRAM REDMAN Activities 377 

IN. 02. 8 What parameters and thresholds are used In REDMAN 
PAGE 13 PROGRAM REDMAN Activities 386 

IN. 03.1 C1B activities scenario needs validation 

PAGE 14 PROGRAM ClB_Act ivit ies 400 

IN. 03. 2 How is Biprop system vented and primed confirmed 

PAGE 14 PROGRAM ClB_Activities 411 

XN.03.3 Do we need to look at the HGA GDE on signal? 

PAGE 14 PROGRAM ClB_Activities 416 

IN .05.1 C1C activities scenario should be reviewed with SCT 
PAGE 17 PROGRAM ClC_Act ivit ies 506 

IN. 06.1 C1D activities scenario should be reviewed with SCT 
PAGE 18 PROGRAM ClD_Activitie« 540 

IN. 07.1 C1-E(P) activities scenario should be reviewed with SCT 
PAGE 20 PROGRAM ClEP_Act ivit ies 608 

IN. 08.1 Cl-E(B) activities scenario should be reviewed with SCT 
PAGE 21 PROGRAM ClEB_Activities 662 

IN. 09.1 Cl-F activities scenario should be reviewed with SCT 
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IN. 10.1 TCM-1 Operational scenario should be reviewed with SCT 
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IN. 11.1 Maneuver scenario should be reviewed with SCT 
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IN. 11. 2 What is MCT responsibility during manuevers 
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IN. 11-3 How do we confirm spacecraft momentum unload 
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IN. 11. 4 What does MCT do on a faulty nanuever 
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IN. 12.1 Payload checkout scenario should be reviewed with SCT 
PAGE 26 PROGRAM C3A 936 

IN. 12. 2 What is the PDS write protect on/off channel number 
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IN. 12. 3 How are three redundant PDS memory readouts confirmed 
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IN. 12. 4 How is command PDS to RAM confirmed 
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IN. 12.5 On switch to S&E-l MBR, is there any effect on GDS 


Figure 5 
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